Rather than opening multiple, you can just push more changes to the same one :)

Thanks, that is just what I was asking, I'll use this draft, but again, I do not want to bother you every time I want to compile a minor change to the PID controller, is there another way so I do not disturb you?

And btw, I see the checks of the different compilations, but I do not get where can I download them (sorry again, very new to this). Thanks in advance :)

Yeah I forgot about the catch with the actions, for a person's first PR they need to be authorised.

If you fork the repo to your own it should run them there for you without drama (you may need to turn them on in the settings of the fork).

To grab the build files you go to the status for the runs then on the left click to go to the summary page and they are at the bottom.
(On phone so don't have link)

But if I keep working on this branch do I need your authorization every time? or now I can work without authorization? if the case is the latter, I do not mind, my goal is not to bother you with every change of the controller constants and also be able to do it as fast as I can. Otherwise, I can set it up but I noted there is a ./github/workflows file I need that I was not able to find in your repository.

Btw I found the hex files, thanks for that also :)

Here is something interesting: I tried the new HEX file from this branch and I got the same alternating flashing light in the heater (red, green and sometimes yellow) in the heating process. I only changed a comment to be able to do the PR. I can not reproduce this behavior with the last release of IronOS for the MHP30. This is both good and bad news, I was apparently able to compile it locally, but there is for sure something different from the published version. Is this expected?

Hi @Ralim I've been playing with the PID parameters and it does not seem to have any effect... I made a plot using a repository I created that shows the time evolution for some configurations. (The default params are P=40, I=6, D=200

As you can see, they all look alike :( I edited the line you mentioned but noticed that the config file is in a folder of the Pinecilv2, but on the other hand, I could not find anything like that for the MHP30.

Do you have any ideas on what might be happening?

Oh sorry, I meant you will need to copy those params into the MHP30 configuration file.

The MHP30 is in the "Miniware" folder, as the MHP30/TS100/TS80/TS80P/TS101 all have very similar hardware they share a lot of code. In the configuration file there are #if model_mhp30 lines that mask out the sections of the file that relate to the MHP30.

If this is confusing I can push up an estimate for your reference

If you can help me with that it would be highly appreciated. No wonder all the curves look the same! hahaha

I managed to change the parameters, I was wondering if there are limits to take into consideration for the controller. I have it quite well-tuned so far but I have a steady state error I cannot get rid of no matter the value of my I constant, so I was wondering if there is a limit to it.

This is the best I have so far:

Note that I am quite sure the power limit affects the performance, here is of 40 W. P=10, I=150, D=500

Ah fantastic, sorry I haven't yet had time to be able to do much.

It's a balance between P and I terms mostly to drop out the steady state error, you can try higher P values (giving overshoot, then use D/I to reduce overshoot).

PID tuning isn't my strong point either, I generally tune to be slightly jumpy rather than perfectly damped as the thermal mass of the tip can make a fairly heavy filter.

Steady state like that shouldn't be affected by the power limit logic.

No worries, I figured you were busy. I've been working on this all day. This is an update:

The problem is that as I increase the temperature, the steady state error gets bigger... I saw the function in charge of controlling this is in the PIDThread.cpp. Is it possible to edit it so I get different parameters for the controller depending on the setpoint? How can I do that? Is it something you might be interested in? For example, implementing fuzzy control seems like an approach that would work here.

@tomasrojasc
I know you contributed the first time and although this is a draft, it would be very nice if you let us know, what this PR is all about, which devices are affected etc. 😊

Please also change the header to something meaningful for that matter, as of now there is not a single hint about what you are up to.

I hope you will be able to achieve what you set out to do.

thanks in advance 👍

Hi @discip, I updated the description and I commited the latest version. There are 2 new issues that I found after working on this:

1. this one is the less important: The light instead of having the normal gree-orange-red colors according to the temp range, now flashes between the correct color and red
2. This is an important one: I cannot go over 190 deg C, as I now describe in the initial comment, it goes back to the main screen shooting down the plate, which is not ideal under any application.

Any help with problem 2? problem 1 does not affect the expected behavior.

I am also adding a table with data from two days of measurements. I waited until the temperature on the display stabilized, then with a thermocouple I measured the actual temperature on the plate. This can be used to transform via software the measured temperature to an estimated version of the temperature using a linear regression. The coefficients of the regression of the displayed temperature versus the measured one are in the figure below:

plate_characterization.csv

As you can see, I cannot go to the hotter temperatures and that I think is a big issue :(

When you go over 200C, what exactly is shown on the screen? (can you grab a photo or short video?)

It doesn't show anything special, it simply goes to the main screen (not the one where you set the temperature, the middle one) I can take a video later today, but it is nothing special, it just goes back to that screen.

Ah okay, if nothing special I'll need to play around a bit more to reproduce. Sorry :(

Is there any log files I can retrieve? maybe that can help in solving this particular problem.

Not really any good logs to extract, the Miniware devices dont have an easy way to get logs out of them.

It is odd for it to reset back to the menu, by any chance as a test could you put a boot-logo on the device to make it obvious if its exiting soldering mode VS a device reset?

Yes, I can do that, sorry for the delay, I've been busy with other stuff. I will try to get a video of the plate working and presenting the problem tomorrow. The plate is in the lab I work and I will not go tomorrow but I'll ask someone to take the video.

No issue with the delay, If I get some time I want to do some more testing on my unit here as well to help out

On the exit at 200C issue; can you try commenting out lines 166-171 in Soldering.cpp to remove the thermal runaway protection. This is my biggest suspicion on what would be causing it.

Hi, again sorry for the delay. Here is a video where I show what happens: https://youtu.be/QAG4nilmnjA

I will try what you are suggesting

Hi @Ralim, I commented the thermal runaway, and it is weird. Now I can reach temperatures well above 200 degrees, but now I cannot keep high temperatures. The temperature falls after reaching a maximum temperature and it does not respond to the setpoint anymore, even though I am now not changed to the main screen anymore.

So, here is a video of the behavior after commenting the lines you suggested. Also another weird thing I notices id that my thermometer reported ~360 degrees while the plate was reporting ~290, maybe in the high temperature range the calibration I did stops working(?) Idk if it is relevant, I only care that the temperature is stable and I can control it, but that was interesting to see.

Edit: Something that may give clues: just before it stopped rising in temperature, the plate beeps twice, the first bee being a bit longer than the second.

I think the plate reporting a lower temperature might be that for high temperatures, the temperature of the terminals of the thermocouple where you measure voltage rises due to convection and conduction, probably mostly convection, hence the temperature difference is lowered. Since the Seebeck effect relies on the temperature difference between where you measure temperature and where the actual thermocouple is located, you get a smaller reported temperature. For me again, this is irrelevant, but it may be useful to know :)

I was thinking about this, and it might be relevant, since the measured temperature will be considered in the PID loop, so we have a problem for high enough temperatures, that might explain what happened(?) Maybe the controller was getting up to the reference and in some part the measured temperature started dropping even when more power was being delivered, this may have caused an issue(?)

I did a test going up in temperature in steps of 10 degrees from 40 degrees. When I set 160, initially the temperature rises as seen in the last part of the attached plot, and then it turns itself off and goes to ambient. Interestingly, now the plate does not return to the main screen, this changed since I commented out the temperature runaway.

I am trying to work with the plate with the commented lines and it is difficult. It is consistently turning itself off at around 170 Deg C, this time it does not return at the main menu.

Here is a picture of the behaviour

@Ralim, any idea of what might be happening?

Regards
Tomás

Hi, this is still not working for some reason :( any new ideas on where the bug might be?

Best,
Tomás

Hmm that is in interesting one; One idea; did you change the scaling / how it reads the tip temperature (i.e. any changes not pushed here)

There is logic that if the ADC that reads the tip temperature is ~= max scaling, we mask off heating to also try and prevent runaway (i.e. if you set the setpoint temperature above what it can measure).

I was thinking about this, and it might be relevant, since the measured temperature will be considered in the PID loop, so we have a problem for high enough temperatures, that might explain what happened(?) Maybe the controller was getting up to the reference and in some part the measured temperature started dropping even when more power was being delivered, this may have caused an issue(?)

We do cold junction compensation; where there is a temperature sensor near the contacts in the base and we offset the read temperature by that temperature

I'm starting to wonder if the temperature readback from the tip is also wrong/out of whack on these models 😓

On a wild punt, have pushed a change; can you try that and see if it improves things or not 😓

Hi, sorry for the delayed response; I've been busy. 😅

I tried the commit you made, and for the first time, I managed to reach higher temperatures. However, the system didn't stay in heating mode for long—it eventually stopped again. Here are a couple of observations:

1. In this run, I set the setpoint to 350°C. Interestingly, I measured temperatures as high as 400°C.
2. At the 300°C mark (as displayed on the screen), I heard a beep.

I've attached the data from this run for your reference. Next, I'll experiment with smaller increments to pinpoint when this behavior starts and determine if it’s related to pushing the system too hard.

Update:
I performed measurements in steps of 10 degrees. Here is the list of temperatures tested: [150, 160, 170, 180, 190, 200, 210, 220, 230, 240].

Below is a plot of the data collected using an external thermometer:

As shown, there is still a moment where the plate shuts down unexpectedly. However, this is an improvement compared to the previous version! The system now reaches up to 240°C.

Do you have any ideas why it cannot reach higher temperatures? Additionally, what specific modifications did you make to the setup?

Best regards,
Tomás